Field of the Invention
Embodiments of the present invention generally relate to digitally signed documents, and, in particular, to a system and method for automated remote credential access and usage in a digital service environment.
Description of Related Art
Mobile health (“mHealth”) is a term for medical and public health practice supported by mobile devices, such as mobile phones, patient monitoring devices, personal digital assistants (PDAs), and other wireless devices. mHealth involves the use of voice and short messaging service (SMS) as well as more complex functionalities such as 3G systems, global positioning systems (GPS), and Bluetooth technology.
The advanced computing capability of smartphones that are typically optimized for internet usage means that individuals can access information and advice (including that related to medical care) from anywhere at any time. The smartphones also provide functionality that is not available via a laptop such as an ability to capture information from sensors on the move and the addition of GPS and camera functions.
A mobile application (or mobile app) is a software application designed to run on smartphones, tablet computers and other mobile devices. Some mobile apps are used to deliver health care information to consumers, or to gather and send health status information from a consumer to a health care provider. Not all mobile apps that have been developed in healthcare are widely available to consumers. Some of the most advanced medical apps are not necessarily designed to target general consumers. Some mobile apps have been designed for healthcare practitioners, others are for patients but require a prescription, and others are intended for only a small subset of patients. Some mobile apps require approval by the U.S. Food and Drug Administration (FDA). A mobile app may also be able to execute on other platforms such as a personal computer (PC) if it has been ported to the underlying operating system, e.g., from Android to Windows or iOS. As used herein, the term “mobile app” may include an application that executes on a PC (e.g., desktop, tower, laptop, netbook, etc.) or other general-purpose consumer computing device, without limitation to a mobile device unless mobility provides a stated benefit or unless otherwise clearly restricted by the context of usage.
Certain patient information is protected by law (e.g., Healthcare Information Portability and Accountability Act (HIPAA) in the U.S.) and must be treated in a way that maintains patient privacy. Such information is termed protected health information (PHI). With respect to PHI, it is important that there is both transparency and awareness of how data entered into a mobile app is used, and that patient consent is obtained for use of PHI data. If a healthcare mobile app collects, stores, and/or transmits PHI, it is essential that it does so in full compliance with HIPAA and any other applicable laws or regulations of the country concerned. Any mobile app that is intended to connect to an Electronic Health Record (EHR) or Personal Health Record (PHR), which enables users to send and retrieve patient information between a mobile device and the EHR/PHR, must do so in a secure manner and all stakeholders involved must accept their stewardship role for protecting the PHI data contained within.
Encryption is a standard tool for ensuring the privacy of communications. A variety of encryption schemes are commercially available to secure protected information, for example the Advanced Encryption Standard (AES), promulgated by the National Institute of Standards and Technology (NIST) as Federal Information Processing Standards Publication 197, Nov. 26, 2001. AES is a symmetric encryption scheme, such that a same cipher key is used for both encoding and decoding. The AES scheme itself exists in multiple variations, such as AES counter mode, AES cipher block chaining (CBC)+cipher text stealing (CTS), RSA, and so forth. Some variations of AES may be described in Request for Comment (RFC) 3962, “Advanced Encryption Standard (AES) Encryption for Kerberos 5,” February 2005, and references cited therein.
A conventional written signature is a human-generated indicia that may be used to indicate authenticity of a document, or to indicate agreement with statements within the document. A digital signature is a mathematical scheme for demonstrating the authenticity of a digital message or document. A valid digital signature gives a recipient reason to believe that a known sender created the message, such that the sender cannot deny having sent the message (i.e., ensure authentication and non-repudiation) and that the message was not altered in transit (i.e., ensure integrity). Digital signatures are commonly used for software distribution, financial transactions, and in other cases where it is important to detect forgery or tampering. Creation and usage of digital signatures commonly involves encryption.
Integral to digital signature and/or encryption is the management of public and private encryption keys. A digital certificate is an electronic document that uses a digital signature to bind a public key with an identity, e.g., a name of a person or an organization, their address, and so forth. The certificate can be used to verify that a public key belongs to an individual. Public-key infrastructure (PKI) is a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates. PKI is known in the art, e.g., as described in U.S. Pat. No. 5,864,667 to Barkan.
PKI binds a public key with a respective user identity by means of a certificate authority (CA). The user identity must be unique within each CA domain. A third-party validation authority (VA) can provide this information on behalf of CA. The binding is established through the registration and issuance process, which, depending on the assurance level of the binding, may be carried out by software at a CA or under human supervision. The PKI role that assures this binding is called the registration authority (RA), which ensures that the public key is bound to the individual to whom it is assigned in a way that ensures non-repudiation.
A drawback to usage PKI services in a disperse environment with mobile apps is that there are many hurdles required for the utilization of PKI services. Mobile app users ordinarily must have some technical knowledge or security knowledge to get started. Mobile app users need to have some knowledge about managing asymmetric keys (e.g., public and private keys), securely storing keys, and securely changing keys locally. Mobile app users usually have a difficult time with the PKI process, e.g., how to start and what to do. Mobile app users ordinarily are not security experts but they are asked to manage PKI credentials or keys. Some mobile app users may be managing PKI credentials and certificate requests for multiple devices, and may find it difficult to keep track of the status of the various devices and their PKI credentials.
Known solutions have addressed PKI management and processes in a manual manner, such that users have to created a PKI key-pair manually and then manage them manually. This is very demanding for mobile app users who usually are not well versed in such procedures. If the PKI key-pair is not managed properly, security may be compromised.
Other known solutions have employed secure elements such as smart cards, Common Access Cards (CACs), and specially configured devices that are used to securely house end-users' PKI credentials. For such solutions, the user must carry additional devices and cards to utilize PKI services. The present commercial practice also includes online services, products and toolkits for developers and end-users to manage PKI credentials and services. In these cases, a manual process for PKI management is still used.
Therefore, what is needed is a more automated process of PKI management without the drawbacks of using additional devices.